# Anthropic 官方 - 提示词精简方法

> 官方砍掉了 Claude Code 80% 的系统提示词，跑分居然没降

大家好，我是程序员鱼皮。

前段时间 Anthropic 在官方博客发了一篇文章，说他们针对 Claude Opus 5 和 Fable 5 这两个新模型，删掉了 Claude Code **超过 80%** 的系统提示词，但在编码评测上的表现居然没有下降。

![](https://pic.yupi.icu/1/1785753504253-ca87d006-a35e-475f-bdb4-7a4b241e3856.png)

我当时的第一反应是：之前我花大力气写的那些提示词，都白写了？

但仔细想想，又觉得很合理。之前写的很多规则，本质上是在弥补旧模型判断力的不足。当模型能力跟上来之后，这些规则反而成了束缚。

这就好比你教一个新手司机开车，需要告诉他红灯停绿灯行、转弯前先打转向灯。但你不会对一个十年驾龄的老司机重复这些话，因为他早就内化了这些规则，你多说一遍反而会让他分心。

这篇文章我就带你看看官方到底是怎么砍的、背后的原理是什么，再通过一组实战对比感受一下短提示词的效果，最后聊聊我们自己写提示词该怎么做减法。



## 为什么提示词要做减法

Anthropic 在他们关于上下文工程的系列博客中提出了 2 个概念，可以很好地解释这件事。

第一个叫 **注意力预算（Attention Budget）**。AI 模型和人一样，工作记忆是有限的。你给它的上下文规则越多，它花在权衡这些规则上的注意力就越多，留给真正干活的注意力就越少。

第二个是 **上下文的边际递减效应**。上下文中的 Token 数量越多，模型精确召回信息的能力就越差。就像你一次性塞给一个人 100 页文档，让他同时记住每一页的细节，根本不现实。

![](https://pic.yupi.icu/1/01_%E6%B3%A8%E6%84%8F%E5%8A%9B%E9%A2%84%E7%AE%97%E4%B8%8E%E8%BE%B9%E9%99%85%E9%80%92%E5%87%8F%E6%95%88%E5%BA%94_compressed_v2.png)

现在你应该明白 Anthropic 为什么要砍这么多系统提示词了吧。

那具体是怎么砍的呢？



## Anthropic 具体改了什么

官方博客中总结了好几个关键转变，我挑几个最有价值的来聊聊。



### 1、从定死规则到让模型自己判断

早期为了防止 Claude 误删代码或乱写注释，团队通过系统提示词把规则写得很死，比如下面这段：

```markdown
默认不写注释。永远不要写多行文档字符串或多行注释块，最多一行简短注释。除非用户要求，否则不要创建规划、决策或分析文档。
```

这种「一刀切」的规则肯定不够灵活。比如有些复杂代码确实需要多行注释，有些用户也有自己的文档偏好。

但没办法，旧模型的判断力不够，不这么约束它就容易乱来，团队只能接受这个折中方案。

到了新模型时代，这条长长的规则被精简成了一句话：

```markdown
写出来的代码要像周围的代码，匹配它的注释密度、命名方式和惯用法。
```

这样一来，模型就会根据项目现有的代码风格来自动适配，而不是被前置规则限制住选择。

![](https://pic.yupi.icu/1/02_%E4%BB%8E%E5%AE%9A%E6%AD%BB%E8%A7%84%E5%88%99%E5%88%B0%E8%AE%A9%E6%A8%A1%E5%9E%8B%E8%87%AA%E5%B7%B1%E5%88%A4%E6%96%AD_compressed_v1.png)



### 2、从给示例到设计好接口

以前有个经典的提示词技巧叫 Few-shot，就是给 AI 举例子。比如 AI 不知道怎么调用某个工具，你就写 3 个示例给它看。

但 Anthropic 发现，在新模型上面，示例反而会限制模型的探索空间，因为新模型的理解能力比你给的示例更强，示例反而把它框住了。

他们的建议是，与其写一堆示例教 AI 怎么用工具，不如把工具本身的用法设计得更清晰。

他们拿 Claude Code 里管理待办任务的 Todo 工具来举例，这个工具有待办、进行中、已完成三种状态，参数名分别叫 `pending`、`in_progress`、`completed`，AI 一看就知道什么意思，根本不需要你再写示例教它。

设计好的接口自己就能说明用法，只有设计得糟糕的接口才需要一堆说明书。



### 3、从一股脑全塞进去到按需加载

以前 Claude Code 的系统提示词里包含了大量关于代码审查、验证等方面的详细指引。这些内容不是每次都用得到，但万一需要的时候又很关键，所以只能全塞进去。

现在 Anthropic 把这些内容拆成了独立的 Skills 技能包，模型在需要的时候才去加载。甚至连一些工具定义也做成了「延迟加载」模式，模型要用的时候才会通过 ToolSearch 去获取完整的工具描述，平时不占用上下文。

这种策略叫做 **渐进式披露（Progressive Disclosure）**，如果你读过本教程编程工具板块「工具实战」目录中的《Agent Skills：通用 AI 技能库》，对这个术语应该不陌生了。

![](https://pic.yupi.icu/1/03_%E6%B8%90%E8%BF%9B%E5%BC%8F%E6%8A%AB%E9%9C%B2%E6%8C%89%E9%9C%80%E5%8A%A0%E8%BD%BD_compressed_v3.png)

这个思路也适用于我们自己写的 CLAUDE.md 和 Skills 文件。很多人喜欢把 CLAUDE.md 写成一个事无巨细的百科全书，觉得如果不写全，模型就找不到。

但 Anthropic 建议把内容拆成多个文件，形成一个树状结构。就像你整理电脑文件一样，不会把所有文档都堆在桌面上，而是按类别分到不同的文件夹里，需要什么就打开什么。



### 4、从手动记忆到自动记忆

以前用户需要手动按 `#` 快捷键把重要信息保存到 CLAUDE.md，现在 Claude 会自动保存和你工作相关的记忆。

CLAUDE.md 的定位也因此发生了变化，Anthropic 建议把它保持轻量，重点写项目中的「坑」和那些模型看代码看不出来的特殊约定。像目录结构、依赖列表这种模型自己就能读到的信息，就不需要再手动写进去了。

![](https://pic.yupi.icu/1/04_%E4%BB%8E%E6%89%8B%E5%8A%A8%E8%AE%B0%E5%BF%86%E5%88%B0%E8%87%AA%E5%8A%A8%E8%AE%B0%E5%BF%86_compressed_v2.png)



### 5、减少矛盾指令

Anthropic 在审查自己团队使用 Claude Code 的对话记录时，还发现了一个有意思的问题。

同一个请求里，系统提示词说的是「适当添加文档」，但 Skills 里又写了「不要添加注释」，两条指令是矛盾的。

虽然模型大部分时候能根据上下文猜到用户的真实意图，但它得额外花精力去处理这些冲突，白白浪费了注意力预算。

于是他们砍掉了冗余的规则，这类矛盾自然就少了很多。

![](https://pic.yupi.icu/1/05_%E7%9F%9B%E7%9B%BE%E6%8C%87%E4%BB%A4%E8%AE%A9%E6%A8%A1%E5%9E%8B%E5%9B%B0%E6%83%91_compressed_v3.png)



## 长短提示词实战对比

原理讲得差不多了，为了直观地感受新模型在短提示词下的表现，我做了一组实战对比测试。

我用的是 Cursor + Claude Opus 5，任务是让 AI 复刻一个 Cursor 网页版，分别用风格完全不同的两种提示词来跑。

第一种是规则堆砌型的长提示词，包含一堆具体的技术要求和开发步骤：

![](https://pic.yupi.icu/1/1785921294571-9f9acde0-232f-4571-8f39-8f8c8f1a464f.png)

第二种是短提示词，就 5 行话，只说了要做什么和用什么方式调研：

```plain
基于 VS Code 开源生态做一个类似 Cursor 的 Web AI 编程工具，
支持 Editor Window 和 Agents Window。
先用 Firecrawl 搜 Cursor 3 的产品设计，
再用 Context7 查 monaco-vscode-api 的 Web 集成方案，
调研完先出技术方案，确认后再写代码。
```

有趣的是，两种提示词在正式写代码之前就表现得不一样了。

在前期调研规划阶段，短提示词那边主动进入了 Plan 模式，先规划好完整的 Todo 列表才开始动手；长提示词那边反而没有进入 Plan 模式，收到指令就直接开写了。

![短提示词规划后的 Todo 列表](https://pic.yupi.icu/1/1785908352580-d2cafcaf-d694-40a9-98e7-3ea556571265.png)

从代码量来看，短提示词版本一共跑出了 12984 行代码，长提示词版本只有 8384 行，少了将近三分之一。

我们正常的直觉可能是，提示词越长、信息量越大、生成的代码量就应该越多。但结果恰恰相反，说明短提示词下 AI 反而更能放开手脚地探索和生成。

从成品效果上来看，短提示词生成的代码一次跑通，而且功能相当齐全。

可以正常切换 Edit 和 Agent 模式窗口，目录树加载正常，文件的增删改查都没问题，代码语法高亮和自动补全也有，甚至连 git 功能都做了。除此之外还支持切换主题、终端可以正常使用、搜索和快捷键也都到位了。最关键的是，Agent 模式可以正常接入模型来生成代码。

![短提示词版本](https://pic.yupi.icu/1/1785913712132-b278c6d8-521a-4d60-9a64-5cb90fef59a0.png)

长提示词生成的效果就有点儿翻车了，放张图大家自己感受一下差距。

![长提示词版本](https://pic.yupi.icu/1/1785942480484-bdb66780-bc13-4d2c-8da3-dc88a18aaa55.png)

得益于 Opus 5 的智能，两种提示词生成的 Cursor 网页版都能正常调用 AI Agent 来生成代码。我把它们都接入了 DeepSeek API，让它们各自写一个贪吃蛇小游戏，用的模型是 DeepSeek V4 Flash，生成过程很丝滑。

短提示词做的 Cursor 在生成代码前会显示思维链和调用了什么工具，整个交互体验更完整。

![](https://pic.yupi.icu/1/1785981173449-df6ee5ce-64aa-456c-87cf-dea06f4dac33.png)

长提示词做的 Cursor 则是直接开写，没有思维链展示。

![](https://pic.yupi.icu/1/1785981359513-9ece52c4-c252-406f-be73-08ca1f401ec9.png)

最后两个版本生成的贪吃蛇小游戏都能正常运行。AI 发展成现在这样，我居然能够轻松地用 AI 编程工具做个 AI 编程工具，然后让做出来的 AI 编程工具再来 AI 编程。

![](https://pic.yupi.icu/1/1785913338340-fa358bbe-5512-4ba6-b2b3-d6366573c3f3.png)

测试做到这里结果已经很明显了。短提示词开发的 Cursor 无论是功能完善度、代码质量还是一次跑通的成功率，都完胜长提示词版本。

核心原因就在于，长提示词把模型的行为框住了，它只敢在你划定的范围内做事。而短提示词给了模型足够的探索空间，模型自己根据对 Cursor 这个产品的理解，主动补全了很多它认为应该有的功能。



## 我们该怎么做减法

以前模型能力不够，对很多产品和技术的认知是模糊的，你必须手把手告诉它每个细节。现在新模型的训练数据更丰富、推理能力更强，再加上有 MCP、Skills 这些工具让模型的探索自由度更高，那些重复的规则反而成了负担，既浪费 Token，又抢占模型干活时的注意力，还容易跟其他 Skills 的规则产生冲突。

那我们该怎么判断一条提示词有没有必要写呢？

我是这样判断的：**如果一件事是这个任务天然就包含的常识，就不用写。** 比如你让 AI 写一个 REST API 接口，不需要告诉它要处理错误、要返回 JSON，这些模型已经知道了。

**如果一件事是这个任务的特殊要求，跟通常做法不一样，才需要明确告诉模型。** 比如你的项目规定所有接口必须用 snake_case 命名、错误码必须遵循某个内部标准，这些才是值得写进规则的内容。

换个角度来说，你的代码仓库本身就是很好的提示词。项目结构、代码风格、测试用例，这些模型都能自己读到并理解。你要做的是把项目架构设计好，而不是把规则写成一篇小作文。



## 用 /doctor 命令自动优化

为了帮开发者跟上这个变化，Claude Code 还内置了一个 `/doctor` 命令（也可以用 `/checkup`），可以自动扫描你的 Skills、CLAUDE.md 等配置文件，帮你检测哪些内容是冗余的、哪些可以精简。

![](https://pic.yupi.icu/1/1785830100705-ba0f3f43-ba78-43e0-bf59-5dabcf2f2c61.png)

具体来说，它会做这么几件事：

- 检查 CLAUDE.md 里有没有写目录结构、依赖列表这些模型自己就能从代码库读到的信息，有就建议你删掉
- 找出没用到的 Skills 和 MCP 服务
- 检测本地和仓库里的 CLAUDE.md 有没有重复或矛盾
- 针对那些不需要每次都加载的内容，建议你迁移到可以按需加载的 Skills 里

而且所有变更都会先给你看报告，等你确认后才会执行，不用担心它乱改你的配置。

我用自己的项目实测了一下，它帮我优化了一部分配置内容，但没有对 CLAUDE.md 做大的改动，说明我这个项目的规则还算健康。

![](https://pic.yupi.icu/1/1785830217113-f4cf3ca0-4d3b-42f7-9dae-a0d8f590bc5b.png)



## 写在最后

AI 编程领域的变化真的太快了。前几个月我还在研究怎么把提示词写得更完美，还觉得项目规则写得越详细 AI 干活的方向就越准确，结果现在官方直接宣布，之前精心打磨的很多规则其实都是束缚。

Anthropic 在官方博客的最后总结了一句话，我觉得特别精妙：**找到那组最小的、高信号的 Token 集合，来最大化你想要的结果。**

以后写提示词，少即是多。Less is More，你的很多提示词真的可以丢掉了。

当然，做减法不等于什么都不写。把需求和目标描述清楚，仍然是最重要的事，只是不用再事无巨细地规定每一步该怎么做了。关于怎么把需求描述清楚，可以继续阅读本板块中的《Vibe Coding 对话工程技巧》和《用 grill-me 让 AI 拷问你的需求》。